The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Networking devices such as routers, switches and gateways may experience events during operation. Examples of events include exceptions, threshold crossings, and notifications of changed behavior. Network management systems (NMS) report noteworthy events to the NMS user. When events are reported using SNMP (Simple Network Management Protocol) Notifications, the NMS must be capable of displaying certain detailed information to the user, this is typically performed by creating a NMS event object which is presented to the NMS user via some type of event log. The NMS also must be able to use detailed sets of information to correlate various “onset” and “abate” types of events, leaving only the last or most severe event in the “active” event log. The events cleared by such correlation are typically counted, or sent to some type of event history log for archive purposes. In addition to correlating matching “onset” and “abate” types of events, it may also be necessary to correlate multiple other types of events, in the case where they represent the same issue, so that only the most meaningful or severe event is presented to the user.
SNMP provides two basic types of objects for use in notifications, columnar and scalar objects. As described in Request for Comments (RFC) 1902 published by The Internet Society, such as in section 7.1.12 and 7.7 of RFC 1902, objects stored in a virtual table are termed columnar objects. In practice, and in this document, objects not found in a virtual table are termed scalar objects. Various specific SNMP Management Information Base (MIB) specification files define virtual tables, the ordered list of table indices, and columnar & scalar objects (including index objects). In addition to a textual name for each object, the MIB also defines an Object Identifier (OID), which is a notation describing the traversal of a hierarchical “naming” tree structure. SNMP object instances form the “leaves” on the naming tree. Therefore, a SNMP object instance may be referenced using an OID starting with a “naming” OID, which represents the object type, and ending with subtree information describing the “instance.” SNMP scalar objects append “.0” to the end of the naming OID. SNMP columnar objects append the ordered set of table indices to the end of the naming OID. The SNMP standards define valid table index types, and the method to transform values of each index type into OID notation. The transformation method for encoding/decoding specific index values is dependant on index type, allowable length, and other information specified by the index object type details in a SNMP MIB. It is not possible to decode indices from an object's OID without this specific knowledge from the MIB definition.
In practice, software applications parse required information from structured SNMP MIB files using a MIB compiler. The output of MIB compilation is typically some combination of (1) configuration: one or more files of standard or propritary data file format, (2) code: one or more source code files, such as stubbed-out procedures, to be customized later. There are many tradeoffs between these two methods. In addition to system performance, one of the more important considerations is the cost of iteratively adding support for new MIB files and distributing this support to existing installations. This cost can be significantly higher if support is added and tested by a 3rd party vendor (not the NMS vendor). Compiling MIB information into a data file allows for an event rule management application, such as discussed below, to create and manage application behavior based on MIB details. Regardless of the method used, the purpose of MIB compiling is to inject MIB details into software application behavior. Once the MIB has been compiled, and the corresponding software application behavior rules are written, the software application can be used.
In the typical event correlation case, onset/abate traps share the same varbind object instance, so event correlation may use the entire OID (naming OID and index values). However, in cases where two SNMP notifications do not share the same varbind object instance, it is often necessary for a NMS to parse and decode the value of one or more indices, from the columnar varbind OID.